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ABSTRACT 

The Central Archive for Reusable Defense Software (CARDS) Franchise Plan is a tool to help 
management, with assistance from CARDS, develop a detailed, tailored implementation plan 
which will prepare the organization to begin the process of software reuse. 

The CARDS Franchise Plan is targeted toward management level personnel and is meant to 
introduce reuse and obtain assistance from programs such as CARDS to do reuse. 

The Franchise Plan presents a planning process for building a reuse infrastructure. To establish 
a reuse infrastructure, the Franchise Plan will describe the steps that need to be accomplished: 

1. Establish management commitment far reuse 

2. Develop: 

a. An Organizational Assessment which defines an organization’s current state of 
affairs, and assesses its potential for reuse; 

b. A Requirements/Implementation Study which determines the organization’s 
requirements for instituting reuse; and 

c. A Reuse Implementation Plan which describes those steps necessary to 
implement a reuse infrastructure. 

This document is an update to CARDS Franchise Plan, STARS-AC-04116/001/11, 30 March 
93. [CARDS93d] 
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1 Introduction 
1.1 Purpose 

Facing shrinking defense budgets, and growing demand for software to control sophisticated :nd 
complex weapons systems, the Department of Defense (DoD) is focusing software reuse efforts 
on life cycle products for all types of software-intensive systems. As stated in the DoD Software 
Reuse Initiative Vision and Strategy document the goal of the DoD is: 

To drive the DoD software community from its current ”re-invent the software ” cycle to a 
process-driven, domain-specific, architecture-centric, library- assisted way of constructing 
software. [DoD92] 

Making domain-specific reuse a part of the way software is developed requires a reuse 
infrastructure be developed. For the purposes of the Franchise Plan, the reuse infrastructure 
is defined as: a combination of policies, processes, technology, and personnel required in an 
organization to incorporate reuse into the software development process. The Franchise Plan 
will define a planning process for building a reuse infrastructure. 

The Central Archive for Reusable Defense Software (CARDS) Franchise Plan is a tool to help 
management, with assistance from CARDS, develop a detailed, tailored implementation plan 
which will prepare the organization to begin the process of software reuse. 

I 2 Scope 

The Franchise Plan is targeted toward management level personnel and is meant to introduce 
reuse and obtain assistance from programs such as CARDS to do reuse. 

The CARDS Program can support the creation of franchises defined as an organization that is 
committed to developing a domain-specific reuse capability, and 

• forms reciprocal obligations and a cooperative partnership with CARDS; 

• has a business agreement with CARDS that enumerates the range and level of 
services to be provided by CARDS and obtained from the franchise; and 

• shares a process-driven, domain-specific, architecture-centric, library- assisted 
technical vision with CARDS. 

To establish a reuse infrastructure, several steps need to be accomplished: 

1. Establish management commitment for reuse 

2. Develop: 
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a. An Organizational Analysis which defines an organization’s current state of 
affairs, and assesses its potential for reuse; 

b. A Requirements/Implementation Study which determines the organization's 
requirements for instituting reuse; and 

c. A Reuse Implementation Plan which describes those steps necessary to 
implement a reuse infrastructure. 

3. Execute the Reuse Implementation Plan by: 

a. Establishing a CARDS Franchise; and 

b. Building a reuse infrastructure. 
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2 Approach To Franchise Planning 

2.1 Prerequisite: Management Commitment 

The success of software reuse in an organization depends on management’s commitment 
to support the implementation of plans and activities, with continual involvement and to 
be strong reuse advocates. [CARDS92b] 

Management, with its control of budgets and strategic planning, should take responsibility for the 
implementation of policies and guidelines which will ultimately lead to institutionalized reuse. 
It is not enough to simply mandate a change; management should get involved in the early 
stages, and stay involved throughout the entire process. Sample levels of management and their 
respective responsibilities are depicted in Table 2-1 [Reuse92] 

Table 2-1 Organizational Reuse Responsibilities 


Organizational Levels 

Reuse Responsibilities 

Direction Level Managers 

Commitment to reuse 

Program Executive Officers 

Allocate resources to establish reuse 

Designated Acquisition Commanders 

Provide vision and strategies 

Provide policies and procedures 

Develop (service-wide) implementation plan 

Provide Incentives Continued Involvement 

Mid-level Managers 

Commitment to reuse 

Program Managers 

Identify and allocate resources 

Develop (organizational) Implementation plan 

Continued involvement Interface with external resources 

I'nit Managers 

Commitment to reuse 

Project Leaders 

Identify and allocate resources 

Team Leaders 

Develop (organizational) Implementation plan 

Continued involvement 

Interface with external resources 

Individual Contributors 

Commitment to reuse 

Implementation Engineers 

Rationale for Reuse 

Continuous Improvement 

Designing with/for Reuse 

Collect lessons learned 


To achieve maximum benefit from a reuse infrastructure and change the way the organization is 
doing business, management has to make a long-term commitment. Management should follow 
up the commitment with training, resources and other investments which may include identifying 
new personnel, such as domain engineers, domain managers, or other reuse or domain experts. 
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Figure 2-1 Planning Phases 

The phased approach is a method used to control the process. By breaking the implementation 
process into phases, the analyst and developer of the plan are forced to think the process through, 
and digest the implications at each step. The phased approach allows "fine tuning" as the process 
evolves resulting in products tailored for the requirements of the organization. 

The Organizational Analysis will provide an understanding of the current state of the organization 
and an analysis of the organization’s potential for reuse. 
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The Requirements/Implementation Study extends the organizational analysis, studies the 
alternatives, produces the requirements for an organizational ieuse infrastructure and an estimate 
of the cost and schedule of implementing reuse. 

Based on the requirements for the organization’s reuse infrastructure, the next task is to design 
in detail exactly how the reuse infrastructure will be implemented and produce the Reuse Im¬ 
plementation Plan. 

Tailoring the process allows the organization to consider what best fits their requirements. 
Budget, personnel, and the organization’s objectives will be major factors in the decision making 
process. The organization should determine their requirements and available level of investment. 
For example, it is conceivable that some organizations will decide to implement a comprehensive 
reuse infrastructure complete with an in-house library and all the support necessary for it’s 
operation. Others may decide on third party libraries as a business solution. Still others may 
use a combination in varying degrees of the two previous scenarios. Whatever solution and to 
whatever degree, the Reuse Implementation Plan should address the pertinent issues such as, 
domain analysis, technology insertion, library access, etc. 

The Organizational Analysis (Chapter 3] describes a process that assesses the business 
requirements and the cnncal success factors necessary to facilitate reuse planning. The 
Requirements/Implementanon Study [Chapter 4] describes a process that assesses the output from 
the organizational analysis, the domain requirements, financial requirements and the software 
process requirements necessary to recommend a strategy for implementing reuse. Chapter 5 
describes the activities that produce the necessary parts of a Reuse Implementation Plan and the 
decisions that must be made pertaining to asset creation, asset management and asset utilization. 

23 Analysis Activities 

The DoD Software Reuse Vision and Strategy [DoD92] depicts the broad range of factors which 
will influence the successful adoption of software reuse. Reuse technology must ultimately 
address many of these factors, including the unique characteristics of application domains, 
business processes, engineering processes, and the critical success factors for software products 
being developed. Since these factors may vary among CARDS Franchises, the supporting 
technology will also vary. That is, a "one-size fits all" technology approach to reuse is unsuitable. 

To support the identification and insertion of needs-tailored reuse technology, two related 
activities need to be undertaken: 

• An Organizational Analysis, to characterize the existing technology, business needs 
and determine critical success factors. This information will provide both the raw 
materials and insertion base for reuse technology. [See Chapter 3 "Organizational 
Analysis"] 

• A Requirements/Implementation Study to identify an organization’s unique require¬ 
ments and the technology needed to support these requirement. [See Chapter 4 
"Requirements/Implementation Study"] 
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Successful reuse adoption involves critical factors identified during analysis. Figure 2-2 illustrates 
the areas that require analysis for reuse infrastructure development: 



Reuse Implementation 
Plan 


Figure 2-2 Reuse Analysis Activities 

• Business Requirements which define the unique attributes of the organization; [3-4] 

• Critical Success Factors which define the "things that must go right" for a successful 
reuse program; [3-5] 

• Software Process Requirements which define the reuse software process that will be 
employed by the organization; and [4-3] 

• Domain Requirements which define the domain driven requirements. [4-4] 
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3 Organizational Analysis 


3.1 Purpose 


For an organization to fully comprehend the benefits of reuse, and to gauge the magnitude of 
change required to achieve the benefits, information needs to be collected and analyzed about 
the organization’s capabilities and objectives. The Organizational Analysis identifies the critical 
success factors (CSFs), key assumptions and existing capabilities. The Organizational Analysis 
will define "where I am", and" where I want to go "and "what capabilities I have to get there". 


32 Approach 


One approach for the organizational analysis is to use interviews, surveys, questions, and 
information on past software development projects to identify the goals and objectives, domain 
infrastructure, the critical success factors and current technology infrastructure. Information 
needs to be collected on personnel, equipment, facilities, and processes dedicated to software 
engineering from both management and technical personnel. 

To increase the understanding of the organization, it’s goals and objectives, the affect 
of reuse on the organization, it is necessary to place the organization in perspective. 
This perspective is accomplished by identifying the organizational units, locations, and 
functions. [MAR90] 

The business requirements will be determined by assessing the organization’s goals, objectives, 
domain infrastructure and technology infrastructure. The information from the analysis of the 
business requirements will provide the knowledge necessary to formulate the critical success 
factors for the organization’s reuse effort. Both the CSFs and the business requirements will be 
analyzed and the Organizational Analysis produced. [See Figure 3-1 ]. 
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Reuse 

Organization’s Implementation 



Reuse Objectives 
Domain Infrastructure 
CSFs 


Figure 3-1 Organizational Analysis 
33 Modeling an Organization 

The structure of an organization can be understood by developing an organizational chart and 
assigning the functions and processes to the proper unit. 

33.1 Organizational Chart 

The organizational chart will provide the management and functional structure for the 
organization. The chart should list the units within the organization using a structured chart. Each 
unit should list as appropriate a manager, functions and processes. Understanding these facets of 
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the organization will facilitate the organizational analysis and the eventual reuse implementation 
plan. 

33.2 Organizational Functions 

Once an organizational chart has been developed, for each unit the activities performed should 
be recorded. For our purposes, those activities directly associated with software development 
will be recorded. Functions are developed as part of strategic planning. 

Possible activities within the software development process could be: 

1. Domain management: domain engineering; 

2. Software development - analysis, design, coding, testing, integration; 

3. Quality assurance; and 

4. Process improvement. 

Organizational Functions may be defined as: 

• A group of activities that together support one aspect of furthering the mission; 

• A function is ongoing and continuous; 

• A function is not based on organizational structures; 

• A function categorizes what is done, not how; and 

• A function name should be a noun or a gerund (a word ending in "ing”). 

333 Organizational Processes 

The processes are those that an organizational unit performs to achieve the unit functions. A 
process at this point addresses the what, not the how. For instance, "perform domain analysis". 
Processes are part of the business area analysis. 

Processes: 


• Are a specified activity in an enterprise that is executed repeatedly; 

• Defined in terms of Inputs and outputs; 

• As having definable beginning and ending points; 
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* Are not based on organizational structures; 

* Identifies what is done, not how; and 

* Are named using an action verb. 

33.4 Summary 

The model of the organization should include: 

1. An organizational chart showing all organizational units; 

2. The persons who manage the organizational unit; 

3. The major business functions; 

4. The processes of each organizational unit 

5. A matrix mapping managers and functions against the following: 

a. Direct management Responsibility 

b. Executive or policy-making Authority 

c. Involved in the function 

d. Technical Expertise 

e. Actual execution of the Work 


3.4 Determine Business Requirements 


To reduce the difficulty of reuse insertion into the way an organization develops software, it is 
necessary to understand the current state of the organization (business and technology practices). 
The Business Requirements will provide the necessary foundation for a uniq ue organization 
tailored Reuse Implementation Plan. To build this foundation, it is necessary to: 

• Identify the business goals and objectives that will form the basis of the reuse goals 
and objectives; [3-4.1] 

• Identify the domain infrastructure and determine if the domain is suitable for 
domain-specific reure; and [3-4.2] 
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• Identify the current state of the organization’s technology infrastructure. [3- 4.3]. 
All of the above factors will be considered to produce the Business Requirements that include: 

• Business goals and objectives; 

• Reuse objectives; 

• Description of the domain infrastructure; 

• Description of the current technology infrastructure; and 

• Requirements for redirection of and addition to the reuse/technology Infrastructure. 


3.4.1 Identify Goals and Objectives 
Rationale 

To help evaluate the information that is gathered during the Organizational Analysis and 
develop the reuse objectives, it is important to identify the business goals and objectives of 
the organization. The goals and objectives of the organization will provide a foundation for the 
recommendations and reuse objectives that are presented in the Organizational Analysis Report. 
They should also reinforce the motivation to institute reuse. 

Input 

Goals can be extracted from a variety of documents in an organization, for example: technology 
plans, monthly reports, executive reports/memos and management documentation. 

Processes 

The reuse objectives will be formed using the organization’s goals and objectives. For example, 
an organizational goal could be "increase productivity" and a reuse objective that can support 
this goal could be "increase the amount of software assets that are reused instead of created 
from scratch". This example shows support of one organizational goal with a reuse objective. 
By supporting management’s goals, the chances of attaining management commitment will be 
increased. 

The goals/objectives can be developed within the context of an organizational chart. Related 
goals and objectives should then be tracked throughout the organizational chart. The higher- 
level goals will help determine the lower-level goals of an organization. For example, goals 
mentioned above may be related on the organizational chart as: 

• Program Executive Officer - "Decrease software costs” (organizational goal) 

• Program Managers - "Increase productivity"; (organizational goal) 
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* Unit Manager - "Increase the amount of software produced by each person"; 
(organizational objective) 

* Team Leaders- "Increase the amount of software assets that are reused instead of 
created from scratch", (reuse objective) 

To determine the business goals and objectives and formulate the reuse objectives, the analyst 
should: 

* Determine the mission and vision of the organization by interviewing management 
personnel; 

* Use the organizational chart to organize goals and objectives; 

* Collect and evaluate written sources of goals and objectives; 

* Interview management to understand their perspective of the organization and any 
problems that may inhibit the goals and objectives; 

* Prioritize the business goals; 

* Formulate reuse objectives that support the organization’s goals and objectives; 

* Agree on the reuse and business objectives of the organization; 

* Determine current potential barriers to activating a reuse program; 

* Discuss solutions to these barriers; 

* Gain executive rapport and involvement; and 

* Determine how reuse can help achieve the goals. 

Typical questions would be: 

1. What are your responsibilities? Are they different from those indicated on the 
organizational chart? 

2. What are the basic goals of your area? 

3. What are the three greatest problems you have had in meeting these goals? 

4. What has prevented you from solving them? 

5. What value would reuse have in this area? 
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6. How are you measured? 

7. How do you measure your subordinates? 

8. What other types of measurement are you expected to make? 

9. What is the current knowledge and skills of personnel? 

10. How would you describe the services provided by your organization? 

11. Do you have a customer demand for many versions of your products? 

12. Do you have a need for prototypes? 

13. Do you have reduced staff to cover future demand? 

14. How well does your management facilitate reuse? 

Output 

The output from this task should document the reuse objectives in context of: 

• The business goals and objectives; 

• The existing organizational structure with goals and objectives associated with each 
unit; 

• Priority of the business goals; 

• Reuse objectives that support the business goals and objectives; 

• Problems that may inhibit the goal; 

• If possible a recommended reuse solution; 

• Business requirements that support reuse goals; and 

• Impact on organization. 

3.4.2 Determine Domain Infrastructure 
Rationale 

To support the DoD Software Reuse Initiative Vision and Strategy it is essential for an 
organization to have a domain that is a candidate for domain analysis and the formation of 
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a generic architecture. For purposes of the organizational analysis a domain is defined as: An 
area of activity or knowledge containing applications which share a set of common capabilities 
and data. 

The identification methodology and evaluation criteria for selecting a domain is a critical first 
step in determining if and/or how to implement reuse at an organizational level. The domain 
infrastructure is determined by evaluating established criteria for domain stability, available do¬ 
main expertise, and existing software processes that could support domain analysis. 

Inputs 

Information will be gathered from studying current and past software projects, interviewing both 
management and technical personnel and identifying the organization’s goals and objectives for 
the future that could impact the implementation of domain-specific reuse. 

Processes 

The following list of questions should be addressed to determine the viability of an organization’s 
domain of interest, the characteristics of the domain and the capabilities of the organization to 
do reuse within the domain: 

• Do well defined software processes exist in the domain? If so, can they be qualified 
and measured (metrics)? An answer of yes will increase the organization’s capability 
to do reuse and measure the impact of the changes imposed by reuse. 

• Is there a sufficient knowledge base to support the domain analysis? Are there in- 
house experts available to analyze the domain? If not, are there resources to hire 
software engineers or consultants? Does codified experience exists that can predict 
technology and provide domain expertise? The amount of organizational (or exter¬ 
nal) knowledge available will help define the requirements for human resources that 
are needed to build a domain-specific reuse capability and will help determine the fea¬ 
sibility of such an endeavor. 

• Is the domain under consideration mature and stable? To do domain-specific reuse 
the available information should be somewhat static with areas of commonality and 
variability definable. Reusable assets should have the potential to be used frequently 
before becoming obsolete or needing major changes. 

• Will the domain form a key part of an organization’s future "business"? Is there 
competition within the domain? Are there opportunities for strategic or short term 
partnerships for development? Doing reuse in a domain should support the organi¬ 
zation’s goals and objectives for the future. 

• Is the size of the market (now and future) far systems in the domain stable and grow¬ 
ing? What is the economic viability of doing business in the domain, from a return on 
investment standpoint? What are the current and predicted market forces which pro¬ 
vide motivation? 
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If domain-specific reuse appears to be a viable alternative for reuse within the organization, then 
domain-specific reuse objectives should be formulated based on the organization’s general goals 
and objectives. 

Typical questions would be: 

• What are the products produced by your area? 

• What application domain or domains are you currently working in? 

• What is the experience level of your personnel within this domain in number of 
years and/or number of domain related projects? 

• What are the number of projects your organization has developed within this 
domain? 

• Do you have a domain architecture that you reuse? 

Output 

The output from this segment of the Organizational Analysis will describe the current domain 
infrastructure by: 

• Producing an analysis of the organizational domain capability and expertise; 

• Generating domain-specific reuse objectives; and 

• Defining the domain-oriented business requirements, such as human resource needs 
for domain analysis, based on the analysis and domain- specific reuse objectives. 

3.4.3 Identify Technology Infrastructure 

Rationale 

In order for an organization to fully comprehend the benefits of reuse and to gauge the magnitude 
of changes required to achieve those benefits, information needs to be collected and analyzed 
about the current technology infrastructure. The Organizational Analysis will identify areas 
where resources need to be redirected or applied. 

Inputs 

The inputs to this process are: 

• The business and reuse objectives, as described above, to provide the context in 
which the technology requirements will be evaluated; and 
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• The processes and organization’s resources such as human, corporate/project 
legacies, and current software and hardware. 

Processes 

Personal interviews, surveys, and information on past software development projects will be used 
to develop alternative solutions and to tailor an approach designed for each organization. Soft¬ 
ware process-related information (e.g.,CASE usage, software methodology) needs to be collected 
on personnel, equipment, and facilities dedicated to software engineering from Management and 
technical personnel. 

Typical questions would be: 

• Do well defined software processes exist within your organization? If so, 
characterize. 

• How do you capture lessons learned? 

• How do you decide trade-off decisions for formulating requirements? 

• Do you review previous projects to formulate requirements for a new project? 

• What automated software development tools are a part of your software 
development process? 

• Do you use a formalized method for developing software? If so what? 

• Are process metrics collected? 

• What product quality metrics are collected? 

• How are the metrics used? 

• What software engineering environment do you use? 

Reuse Capability 

• Do you reuse any portion of previous projects on current projects? If yes: 

• At what time during the life-cycle do you incorporate the reusable parts? 

• What is the estimated percentage of current projects that are reused parts? 
a Do you have a library far reusable parts? If so, characterize contents. 

• Is reuse done on an individual, team or organizational level? 
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• Is the concept of domain analysis an accepted part of your software development 
process? 

• What languages are used in the reusable parts? 

• Is there an organization unit responsible for developing reuse action plans? 

• Is there a formal or informal way of identifying reuse opportunities 

• Is planning for reuse part of the project planning cycle? 

• Is data on the investment in reuse maintained? 

• Are reusable assets created by an independent development team? If yes, how many 
people are involved and what are their roles? 

■ Is there any special training provided for creating reusable software? 

• How important are tools in creating reusable assets? 

• Are there any standards used for constructing reusable assets? 

• Did you collect any metrics on the development of reusable assets? 

• Is an organization unit responsible for reusable libraries on a project? 

• Who is responsible for the horary? 

• Describe the services available from the library? 

• Are library usage metrics collected? 

• How has library usage changed over time? 

• Is there an asset certification process? 

• Is there an asset qualification process? 

• Do you have agreements for providing reusable assets to external groups or 
organizations? 

• What has facilitated/impeded the reuse of available components? 

• Have testing practices changed since introducing reuse? 
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• Do you have agreements for using reusable assets form external groups or 
organizations? 

• Do you provide usage reports back to the library? 

• What are the goals of your reuse program? 

• What up-front investment was required to add reuse to your process? 

• What success have been achieved? 

Outputs 

The outputs from this segment of the Organizational Analysis will identify the resources 
available to build a reuse infrastructure and the business requirements for redirecting those 
resources. To build a reuse paradigm in an incremental fashion, we should consider utilizing the 
current technology within the organization whenever possible. We need to describe the current 
infrastructure in terms of: 

• Software process being used; 

• Operational hardware and software; 

• Quantity of software produced; 

■ Quantity and quality of assets currently available; and 

■ Controls that are in place, for metrics collection and analysis. 

3.5 Identify Critical Success Factors 

Rationale 

Critical Success Factors (CSFs) are the limited number of areas in which satisfactory results will 
ensure competitive performance for the individual, department, or organization. CSFs are the 
few key areas where "things must go right" for the organization to flourish and the manager’s 
goals to be attained. [MAR90] 

Inputs 

The inputs to CSF analysis are f he business/reuse goals and objecdves[3.4.1], corporate expertise 
in the application (domain infrastructure) area [3.4.2], and the current technology infrastructure 
[3.4.3]. 

The goals and objectives are needed to determine the management CSFs, such as organisational 
commitment, planning and direction. The current technology will help define the tools support 
and technology innovation that may be critical to an organization’s reuse effort. 
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Application expertise is needed to characterize the attainable CSFs related to the technical 
attributes of software assets and the products developed from them; this expertise will be tapped 
through structured interviews with selected application experts within domains of interest to the 
organization. 

The Reuse Capability Model (RCM) [SPC92b] provides a source for possible CSFs. The factors 
are organized into four groups; management, application development, asset development, and 
process and technology [See Table 3-1 ]. The management factors correspond to issues critical 
to management’s role in facilitating reuse. The application development factors correspond to 
issues critical to the utilization of reusable assets in the development of end products. The 
asset development factors correspond to issues critical to the acquisition or development of 
assets for reuse. The process and technology factors correspond to general process issues which 
are applicable across the management, application development, and asset development views. 
[SPC92b]. 

Table 3-1 Possible Critical Success Factors [SPC92b] 

Application Development 

Asset Development Factors 

Factors 

Asset awareness and 

Needs identification 

accessibility 

Asset interface and 

Asset identification 

architecture definition 

Asset evaluation and 

Needs/solution definition 

verification 

S imiianty/v ariadon 

Application integrability 

definition 

Asset quality 

Processes 

CSFs may be identified in a top-down fashion. First establish CSFs for the executive branch of 
the organization and then for each branch below on the organizational chart. The CSFs will be 
defined in terms of one or more business goals and objectives and the reuse objectives. 

In order to support the CSFs or as part of the CSFs, three other things must be considered: 

• Critical Assumptions which are a group of assumptions about a business segment 
that supports or validates an organization’s CSFs; 

* Critical Decisions that must be made by an organization to have an impact on its 
CSFs; and 


Asset value determination 
Asset reusability 


Management Factors 


Organizational commitment 
Planning and direction 
Costing and pricing 
Legal/contractual constraints 


Process & Technology 
Factors 


Process definition and 
integration 


Measurement 


Continuous process 
improvement 


Training 


Tool support 


Technology innovation 


Page 19 







































STARS-VC-BOKVOOl/OO 


28 February 1994 


* Critical Information that is required by an organization’s operational system to 
enable them to support the organization’s CSFs. 

A proposed methodology [MAR90] would include: 

* Preparing for the CSF analysis by learning all about the organization and external 
relevant information (organizational information determined while de fining the 
business requirements); 

* Holding an introductory workshop to illicit information from top management that 
will lead to identification of the CSFs; 

* Conducting individual interviews with management and technical personnel; 

* Producing a consolidated report; and 

* Reviewing and distributing the consolidated report to top management. 

Discuss the interviewee’s view of the organization. Determine that the interviewee under stands 
CSFs and the purpose of the interview. Have the interviewee describe his role and mission in the 
organization. Have the interviewee identify their goals. Discuss problems that the interviewee 
perceives within the organization. 

Three questions that may help elicit the CSFs are: 

1. What are those things you see as critical success factors for your job at this time? 

2. In what one, two, or three areas would failure to perform hurt you the most? Where 
would you hate to see something go wrong? 

3. If your were isolated from the organization for two weeks, with no communication 
at all, what would you most want to know about the business? 

To check the validity of the interview, the interviewer should determine if: 

* Have external CSFs been considered as well as internal CSFs: for example, 
regulatory mandates, market forces? 

* Have building CSFs, those that change the organization structure or processes, been 
considered: for example, restructuring the organization, new product lines, uses of 
new technology? 

* Have short-term factors been considered: for example, current crisis, budget 
overruns? 

* Have CSFs been considered that relate to: 
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* the position or viewpoint of the manager of the organization? 

* activities of competition? 

* the industry in general? 

• Make sure that the list is not limited to CSFs that are appropriate to reuse only. The 
objective is to elicit all software development needs. 

• Eliminate redundant CSFs. 

• Ensure that past and future concerns are discussed as well as the present. 

The CSFs should be prioritized in some manner. It is also important to discuss the measurement 
of the CSFs. 

Outputs 

The output of this process is the identified, prioritized CSFs based on the business goals and 
objectives and the reuse objectives. The prioritization of the CSFs will depend largely on how 
the business goals, objectives and reuse objectives were prioritized. 

3.6 Perform Analysis 

As shown in Table 3-1, an analysis activity occurs that analyzes the CSFs, and the business 
requirements, as described above, and consolidates the information into a cohesive organizational 
analysis of reuse maturity. 

This analysis activity should address these issues: 

• How can the organization’s goals and objectives be supported by reuse? 

• Can the current software and hardware support a reuse program? 

• What are the software maturity capability factors related to reuse success? 

• What are the reuse objectives? 

• What are the critical success factors? 

• What resources can be committed? 

The Reuse Capability Implementation Model [SPC92] has arranged the CSFs for each category 
by reuse capability stages. For each CSFs the RCM identifies goals that should become part of 
the reuse strategy at various capability stages. Using the RCM and the information collected 
thus far assess the reuse capability of the organization in the short term and the long term. 
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Identify those aspects that are clearly feasible now and the reuse CSFs that may not fit into the 
organization’s business goals and framework. 

Output 

An Organizational Analysis report that contains: 

• The reuse/technology infrastructure; 

• The reuse objectives and business goals and objectives; 

• The domain infrastructure; 

• The critical success factors; 

• An analysis of reuse maturity based on the current goals and objectives and the 
technology infrastructure; and 

• A recommendation as to what level of reuse is feasible for the organization, for 
instance domain model, architecture, or implementation asset reuse. 

See "Organizational Analysis Sample Outline" on page A-l. for suggested content areas for this 
analysis report. 
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4 Requirements/Implementation Study 

4.1 Purpose 

The Requirements/Implementation Study will balance requirements imposed by an organiza¬ 
tion’s; reuse objectives, technology infrastructure, critical success factors, software process and 
reuse process maturity, process improvement strategies and characteristics of the underlying ap¬ 
plication domain to produce a specification for an organization-tailored reuse infrastructure. 

The Organizational Analysis provided an understanding of the domain, objectives and goals, 
current technology environment and critical success factors of the organization. Based on 
this information, the purpose of this Study is to identify the appropriate reuse infrastructure 
requirements for an organization. 

The Organizational Analysis defined "where I am”, "where I want to go" and "what capabilities 
do I have to get there". This Study will define "how do I get there" and "is it cost effective". 

4.2 Approach 

Figure 4-1 depicts the four tasks that will determine the Reuse Infrastructure Requirements. 
Two primary tasks identify the software process and domain requirements. A third task of equal 
importance is the impact analysis. Once all the information is gathered and the impact assessed, 
then the data is analyzed to produce the Reuse Infrastructure Requirements. 

The software process requirements will be developed by evaluating the existing software 
processes, the reuse/technology infrastructure, the reuse objectives, the domain infrastructure 
and CSFs. The current capability models [STARS92c, SPC92b] for software process maturity 
should be used as references to develop feasible requirements. 

Given the organizational analysis and the legacy software available within the domain, the do 
main requirements should be developed and provide requirements for the classification scheme, 
domain engineering method and support needs. 

Given all the requirements, as described above, the impact to the organization needs to be 
determined. 

The final activity assimilates the technical and business requirements, performs requirements 
feasibility and trade-off assessments, and ultimately harmonizes the reuse infrastructure 
requirements and balances competing needs. 

43 Identify Software Process Requirements 

Rationale 

To determine the Software Process Requirements, it is necessary to evaluate the current software 
process for reuse potential and identify the software process factors. The software process factors 
are: 
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Figure 4-1 Requirements/Implementation Study 

• The reuse-oriented characteristics of the software development process; 

• Reuse usage patterns, such as when in the software development life cycle reuse is 
attempted; 

• What information will be available to the engineer at the time of reuse; and 

• How the users want the information presented must also be considered. 

Inputs 

Inputs to this task are: 

• Long-Term Business Objectives; 

• Reuse objectives and committed resources; 

• Technology infrastructure; and 

• Domain Infrastructure. 


Processes 
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Techniques for analyzing software process factors include an analysis based on user surveys and 
surveys of technical project leaders, and evaluation of existing software development processes 
and software development standards for reuse insertion potential. 

Software development plans for : xisting or anticipated reuse consumers as well as organization 
"software process" standards will be evaluated; these identify the form and content of reuse as¬ 
sets, as well as the timing in the life cycle when reuse will apply. 

The objective is to fit reuse into the current software process with the least amount of difficulty. 
Outputs 

The software process requirements should include: 

* Software reuse process requirements and reuse usage scenarios; 

• Insertion of reuse-driven processes into the current software processes; 

• Any recommended changes to the software development processes; and 

* Current or potential automated support for a reuse inserted software process. 


4.4 Identify Domain Requirements 


Rationale 

Domain requirements refers to those requirements introduced by the nature of the software 
being reused. For example, evaluating the prospects for architecture and feature recovery of the 
reusable software is needed when existing code, not designed for reuse, will constitute the bulk 
of the asset population. 

In support of the DoD Software Reuse Initiative Vision and Strategy, we recommend pursuit of 
a reuse plan that includes domain analysis and modeling, generic architecture development, the 
creation/acquisition of domain-specific reusable assets and library support develop ment. 

Inputs 

Major inputs to this process include: 

• Reuse objectives, already described; 

* Domain infrastructure identified during the Organizational Analysis; 

* Software documentation; 

• Relevant CSFs; and 
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• Associated technical expertise related to the population of reusable assets and their 
underlying application domain(s). 

Processes 

During the Organizational Analysis the domain infrastructure was identified. The Require¬ 
ments/Implementation Study will produce a report that enumerates the domain requirements for 
the organization. This information should be available for the asset creation, asset management 
and asset usage planning effort. 

The implementation alternatives should be evaluated based on the current software processes, 
tools support and personnel. For example, if the organization uses a structured analysis approach 
to software development then the domain analysis methodology requirement could be "Domain 
Analysis shall be implemented using a structured analysis based approach". 

Since domain analysis is relatively new, there are several domain analysis processes in existence 
with diverse goals, products, and processes. Determining the best approach to domain analysis 
requires considering the context in which the approach will be used. 

Domain analysis approaches are considered in the context of five factors [WAR92]: 

1. Current software process needs: 

a. Some domain analysis techniques are intended for a certain process model, e.g., 
waterfall. 

b. Where does domain analysis fall within the software process? 

c. Can the existing process be changed to incorporate domain analysis? 

2. Existing knowledge/software base: 

a. Availability of domain experts. 

b. Availability of existing applications within a domain, e.g., access to the 
application and source of analysis and reusable assets. 

c. Possible evolution of the domain’s technology. 

3. Business objectives: 

a. How are the domain analysis products used? 

b. Organization must understand long and short term needs of domain analysis. 

c. When will the cost of the domain analysis be recovered? 
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d. What are the organizations’s current and future needs? 

e. Are there any plans for domain evolution? 

f. Is there a plan prioritizing domain analysis and implementation efforts to meet 
the organization’s needs? 

4. State of domain knowledge: 

a. Maturity of domain affects the cost of doing domain analysis, (i.e., a poorly 
understood domain could result in minimal benefits in comparison to the cost). 

b. Chose a domain analysis method that can take advantage of the well understood 
areas of a domain. 

5. Domain products: 

a. What will be the domain analysis products? (i.e., domain model, generic 
architecture and domain-specific reusable assets) 

b. Who will use the domain analysis products? 

c. How will the products be used? 

Outputs 

The analysis should take into consideration all the above factors when deciding on the method, 
tool support and personnel requirements for defining the domain requirements, such as: 

• Identified business and reuse objectives supported by domain requirements; 

• Additional reuse objectives; 

* Requirements for domain evolution; 

• Recommended classification schemes, including (but not limited to) faceted, 
hierarchical, feature and semantic-model-based classification schemes; 

* Recommended methodology for domain engineering; 

* Recommended tool support and integration with current environment; 

* Additional hardware and software needs; and 

• Personnel requirements for domain engineering. 
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4i Determine Impact 


Rationale 

The level of investment should be determined up front and management should be prepared to 
commit the resources needed for implementation. The negative impact of insertion or adoption 
of new technology needs to be controlled and understood before implementation. To develop 
the requirements for change or redirection of the technology infrastructure, we must understand 
the impact of various alternative reuse methodologies, software process support, personnel re¬ 
quirements and implementation strategies (i.e., phased approach vs. all at once). 

Inputs 

The inputs into this activity are: 

• Reuse/Technology infrastructure; 

• Reuse objectives; 

• Domain infrastructure; 

• CSFs 

• Process Requirements, tools support and alternatives; 

• Domain Requirements, including classification schemes, domain engineering, and 
tool support; and 

• Economic models. 


Processes 

The activities that will be used to evaluate the effect of reuse insertion into the way the 
organization develops software include: 

• Define the potential impact of change on personnel; 

• Determine levels of bias toward reuse. Institutionalized software reuse is rela¬ 
tively new and consequently misunderstood. As with any new technology, much is 
lost in the translation between technical capabilities and the potential of the tech¬ 
nology in a user's specific application of that technology. 

• Analyze current skill levels of personnel affected. Institutionalized reuse will re¬ 
quire training in new skills. The degree to which new training is required will 
depend on current skills, education, and experience. 
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• Define skill level requirements for proposed change. Based on the current skill 
levels of personnel relate the impact of any proposed hardware, software, and en¬ 
gineering expertise required. 

• Define equipment requirements; 

• Analyze the need to add additional personnel and the potential impact on current 
personnel, budgets, etc., in additional to adding or upgrading existing equipment. 

* Define the software development process changes that will be necessary and im port 
on: 


• Personnel; 

• Equipment; and 

• Current tools. 

• Define budgetary impacts of implementing the proposed solutions. This process is 
repeated until there is a satisfactory and practical solution for the organization. Ev¬ 
ery attempt should be made to determine a target budget at the onset of the planning 
process. 

• Estimate the cost for a reuse infrastructure at an organizational level: 

• Include costs for all required consulting services, hardware, software, software 
support services, costs for incentives, royalties, license fees. 

• Consider the cost of different requirement implementation alternatives. Estimates 
for different alternatives will be used to determine how well the organization's re¬ 
quirements will be met. 

• Consider various costing scenarios such as, phased implementation, initial 
investment, etc. 

• Summarize all assumptions made. Assumptions should be clearly identified to re¬ 
duce or manage risk. As the assumptions are validated, a clearer overall picture 
will emerge and decision points can be approached with a higher level of confi¬ 
dence. 

• Estimate the gross return on investment: 
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• Estimate potential long-term savings from reuse. Factors such as: stability of 
domain, existing and future technology, and market trends will be analyzed to 
produce best and worst case scenarios. 

• Estimate potential business opportunities. Other factors such as: access to broader 
markets, current research and development being conducted by other organiza¬ 
tions, availability of reusable assets (requirements, documentation, specifications). 
Also consider innovative approaches such as, teaming agreements, joint venturing, 
partnerships with universities, federally funded research and development corpo¬ 
rations. 

• Determine feasibility of adding additional equipment and associated costs; 

• Estimate current organizational personnel requirements; 

• Estimate personnel requirements by category (such as: software engineer, domain 
engineer, program manager, acquisition officer, etc.). Consider all Personnel ded¬ 
icated to the implementation and ongoing reuse process. Include management and 
system/software engineers. 

• Estimate number of required support personnel by skill category. Support person¬ 
nel includes those assigned on a full time basis, such as library administrators, 
hotline or user support, and personnel such as consultants, facility maintenance, 
upper management or others as required. 

• Estimate on-going training requirements. Consider formal education, seminars. 
workshops, etc. 

• Ensure that the following issues are addressed within the 

Requirements/Implementation Study: 

• Major Risks. 

• Legal issues. 

• Scheduling requirements for implementation. 

4.6 Analyze Data 

The Requirements/Implementation Study activity considers all the information produced in the 
above activities and during the Organizational Analysis; and produces the Reuse Infrastructure 
Requirements. As shown in Figure 4-1, the "Analyze Data" activity assimilates the technical 
and business requirements, performs requirements feasibility and trade-off assessments, and 
harmonizes the reuse infrastructure requirements and balances competing needs. 
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The resulting analysis should produce the Reuse Infrastructure Requirements which should 
consolidate the: 

• Goals and objectives; 

• Business Requirements; 

• Critical Success Factors; 

• Software process requirements; 

• Domain requirements; 

• Impact Analysis; 

• Estimated Cost and Schedule; 

• Constraints imposed that may limit the alternatives during the development of the 
Reuse Implementation Plan, such as use of a specific CASE tool for software 
development; 

• Recommendations; and 

• Technical documentation to support concept exploration and design trade-off 
analysis. 

See "Requirements/Implementation Study Sample Outline" on page A-2. for a recommended 
Reuse Infrastructure Requirements Report content. 
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5 Reuse Implementation Plan 


5.1 Purpose 


The purpose of the analysis activities previously described, was to identify the appropriate 
technology and business practices to meet organization needs. The purpose of developing a 
Reuse Implementation Plan is to provide the organization a tailored need-based plan that balances 
reuse needs with the current organizational environment. 

The Reuse Implementation Plan will organize the overall reuse objectives and strategy, and 
requirements as they pertain to asset creation, asset management and asset usage into a cohesive 
plan. 

The Reuse Implementation Plan should support senior management’s efforts by: 

• Ensuring that the organization is focusing on the reuse objectives; 

• Cascading the reuse mission, vision and goals of the organization throughout the 
entire organization; 

• Identifying the critical processes that need attention and improvement; 

• Identifying the resources and the trade-offs that must be made to fund the reuse 
effort; and 

• Reviewing progress and removing barriers that are identified. 


5.2 Approach 


The results of the Requirement/Implementation Study will be used by managers, senior systems 
analysts and software engineers to develop the Reuse Implementation Plan. 

The reuse objectives formulated in the Organizational Analysis becomes the basis for the Reuse 
Implementation Plan. The Plan should support these goals and objectives. 

The three primary tasks in Figure 5-1 illustrates the three primary areas that need to be addressed 
when developing a Reuse Implementation Plan: 

• How and what assets will be created; 

• How the assets will be managed; and 

• How the assets will be used 

based cm the reuse objectives and infrastructure. 
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Figure 5-1 Reuse Planning 
53 Develop Plan for Asset Creation 
Rationale 

The Requirements/Implementation Study, described in chapter 4, will be used to support the 
preparation of an asset creation plan. The decisions to be made include: 

• How assets will be captured and organized; 

• How knowledge about a domain will be represented; and 

• How reusable assets will be produced. 

Inputs 

The inputs needed to plan for asset creation include: 

• The business objectives; 
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• The reuse objectives, especially the domain-specific objectives; 

• The current environment; and 

• The reuse infrastructure requirements. 

Processes 

Based on the decisions made while analyzing the domain requirements [4.4], the organization 
should design an implementation plan for asset creation. The domain requirements described 
the organization’s required needs to execute a successful domain-specific reuse program. The 
asset creation plan will identify the resources for implementing the domain requirements. The 
resources will include; human, automated tools support, implementation of a domain «*ngim»fring 
method and an asset development method. 

Outputs 

The plan should enumerate; 

• What assets will be developed such as, domain model, generic architecture, and 
implementation assets; 

• What assets will be available from existing software base?; 

• What changes to the software development process are necessary?; 

• What methodology will be used to create assets?; 

• What tools are necessary?; 

• Impact on personnel, budget and the organization; 

• How the products of domain analysis will be used. Will the products, models, and 
architectures be used to identify areas in the domain which need to be stabilized? 
Will the organization use the information to enhance Requests For Proposals (RFPs) 
and proposals?; 

• What is the effect of new technology on the domain? Can the available technology 
enhance the performance of assets in the domain?; 

• What domain analysis method will be used (i.e., Prieto-Diaz, Feature Oriented 
Domain Analysis)?; 

• Who in the organization will be responsible for asset creation?; 

• What training will be necessary to enact asset creation?; 
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• What is the implementation timeline for asset creation? and 

• What are the specific objectives for asset creation? What business and/or reuse 
objectives do these objectives address? 

5.4 Develop Plan for Asset Management 

Rationale 

Part of the Reuse Implementation Plan needs to include a strategy for asset management. Based 
on the requirements analysis, business objectives, reuse goals and CSFs identified previously, 
several decisions will be made. 

The organization must decide on the type of library, if any, in-house vs. third-party library, 
technology support and management structure that will be used. The assets within a reuse 
library, their organization and the means to retrieve them can all support (or hinder) CSFs; 
conversely, CSFs may suggest technical implementation concepts such as asset quality attributes, 
asset generators, or automated asset composition. 

Inputs 

The information needed to develop an implementation plan for asset management include: 

• Business requirements; 

• Reuse infrastructure requirements; 

• Business objectives; 

• Reuse objectives including the domain-specific objectives; 

• Impact analysis; and 

• Current environment. 

Processes 

There are several issues that should be addressed: 

• Does a library exist that meets the organization’s needs? 

• Would the organization get a return on investment by implementing an in- house 
library? 

• Hardware availability; 

• Software availability; 
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• Trained personnel; 

• Training and education for library personnel; 

• Training and education of users; 

• Library model availability; 

• library population; and 

• Library maintenance. 

• Should the organization use a third-party library? 

• Communication link availability; 

• Means of transferring data between the user and the library as well as hours of 
operation become issues which may or may not be open for negotiation; 

• Hardware availability/compatibility; 

• Software availability/compatibility; 

• Training and education of users; and 

• Memorandum of Understanding (MOU) with third party library. 

• How are assets qualified, certified and validated against domain requirements? 

• How will asset management affect and be affected by asset creation and asset usage? 

• What additional resources will be necessary for asset management? Are these 
resources easily available? 

Outputs 

This part of the Reuse Implementation Plan needs to; 

• Define library needs; 

• Define how assets will be acquired, stored, accessed, and m aintain^; 

• Define the types of products suitable for reuse and develop criteria to validate these 
assets for new applications; 
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• Define standards for the various types of assets which will permit their certification 
for reuse; 

• Define who is responsible for managing and maintaining the assets; and 

• Define the tool support required, if any for asset management. 

5.5 Develop Plan for Asset Usage 

Rationale 

The organization needs to formulate a plan to describe how and when in the software development 
life cycle reusable assets will be available. This plan needs to incorporate incentives far the 
potential users of the assets. It must provide for feedback to the other processes. Integration 
with current processes may be vital to realize the full potential of reuse. 

Inputs 

The inputs that support creation of a plan for asset usage are: 

■ Current software process information; 

• Domain information; 

• Anticipated changes to the software process; 

• Asset Creation decisions; and 

• Asset Management decisions. 

Outputs 

This part of the plan must provide for: 

• Identification of the reuse processes and tools to be employed in using the assets, 
such as: 

• Software development processes with domain-specific reuse; 

• Automated tool support; and 

• Integration of library tools. 

• The mechanisms and process for feedback to the management and asset creation 
process; 

• Integration of assets into current software development tools, such as CASE tools; 
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* Incentives to the potential asset consumers to get their cooperation both in using the 
assets and providing assets and feedback; 

* How assets can be identified by the user; 

* Guidance and support for the end user that facilitates the reuse implementation plan. 
5.6 Converge Plans 


The areas described above, are strongly interwoven because decisions made in one area will 
influence decisions made in another area (i. e„ assets created will strongly affect asset 
usage). Therefore, a spiral development method for creating the Reuse Implementation Plan 
is encouraged. 

The Reuse Implementation Plan should converge all the requirements defined by the Require¬ 
ments/Implementation Study and balance these requirements against the cost of different imple¬ 
mentation scenarios to produce a plan that is both feasible and supports the reuse objectives of 
the organization. 

The Reuse Implementation Plan should also consider that the introduction of reuse technology 
too quickly may not be effective, because: 

• Ill-defined or non-existent software processes will inhibit the acceptance of new 
technology; by the time such "uptake" is feasible, alternative and more powerful 
technologies may be available on the market; 

• The selection of technology may be faulty since a stable process was not available 
for defining the technology selection criteria; and 

• Too rapid and haphazard introduction of technology may result in chaotic, processes 
and introduce too many variables to permit reasonable reuse impact assessments; and 

• Therefore, an organization should take an iterative approach to implementing reuse. 
The Reuse Implementation Plan needs to enumerate: 

• The reuse objectives; 

• The domain of interest, current software development methodology, tool support, 
training needed, and estimate cost and development time; 

• The software development process changes and a timeline for these changes; 

• The technology support functions and tools necessary; 
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• An asset creation, management and usage strategy; 

• An impact analysis; 

• Cost and schedules; 

• Personnel requirements; 

• A project management plan; and 

• A measurement plan for evaluating the reuse infrastructure and progress of the reuse 
program. 

See "Reuse Implementation Plan Sample Outline" on page A-5. for suggested content areas for 
this plan. 
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6 Cost and Schedule 
6.1 Purpose 

The purpose of this section is to guide the organization toward estimating cost and schedule for 
a specific Reuse Implementation Plan. By collection and analysis of cost data, the organization 
can apply realistic estimates to various schedules for the establishment of a reuse infrastructure. 

The costs which are identified up front during the Organizational Analysis can be monitored to 
evaluate the future impact or benefit of reuse. 

6i Approach 

The organization should perform a detailed analysis that measures the potential costs and 
benefits of reuse to an organization (across one or more departments or divisions). Information 
previously addressed in this document [chapters 3 and 4] as well as certain concepts detailed 
below will be used to perform this analysis. This approach will require an in-depth work 
study survey which computes the potential for savings for selected activities such as: software 
development processes, potential for reuse, domain factors, personnel factors, organizational 
mission, resources, facility and communication factors, and other factors which may be identified 
as critical to doing business (intangibles). This section will also provide some standard formulas 
used to calculate Cost Benefit Analysis and returns on investment. 

Input 

The information required for accurate analysis will be obtained from various areas of the 
organization. Based on the magnitude of change involved in institutionalizing reuse, different 
levels of financial detail will be required. 

Processes 

The process can be broken down into several steps: 

1. Investigate reuse objectives and requirements 

This involves studying the current operations, problems, and reuse opportunities 
within the organization and its domain. Business objectives and constraints are 
identified and a conceptual model of the reuse infrastructure is developed to meet 
the objectives [Section 3.4]. 

2. Organization capabilities 

An organizational analysis is conducted using surveys, interviews, and question¬ 
naires. A sample work sheet is provided [See Appendix A.4] which, when com¬ 
pleted, will indicate the organization’s level of expertise in critical areas of the 
reuse infrastructure [Section 3.5], 
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3. Quantify organizational resources 

Identify human, corporate, and budget factors which will enhance or contribute 
to the various reuse implementation plans [Section 4.5]. 

4. Estimate the benefits (potential long term savings and potential business 
opportunities) 

Once the conceptual model of the reuse infrastructure is developed, the benefits 
resulting from achieving the business objectives are identified and estimated. 
These benefits are then scheduled over the projected life of the system. 

5. Estimate the costs (infrastructure costs at organizational level) 

A plan for the proposed reuse infrastructure, showing the operational hardware 
and software configuration, is derived from the functional requirements. Major 
components of the system are identified. Hardware and software costs, and new 
operating and maintenance costs are estimated [Section 4.5]. These costs are then 
scheduled over the life of the system. 

6. The cost and benefit analysis 

Applying cost-benefit techniques begins with reviewing the current environment 
(organization) and the reuse goals or anticipated future benefits. A financial 
analysis of the proposed system is performed using the estimated and quantified 
benefits and costs. Various financial indicators measuring the financial worth of 
the proposed infrastructure are calculated. 

7. The interpretation of the analysis 

Once the financial indicators measuring the financial worth of the project 
are calculated, they are evaluated with respect to the business objectives and 
constraints of the organization. The results are evaluated and validated for 
consistency and soundness according to the standards and procedures of the 
organization’s financial oversight authority. 

8. Presentation of the analysis 

The final results of the analysis are summarized with all assumptions and 
estimations identified. This will allow for fine tuning and risk analysis/control. 

63 Investment Summary 

The fundamental concept behind the analysis of investment decisions is cost-benefit analysis. 
It is a procedure for organizing facts to determine the worth of a project. Simply, the costs 
associated with a project are compared to the net benefits expected from the project. 


Page 41 







STARS-VC-BOKVOOl/OO 


28 February 1994 


The cost-benefit analysis will produce an estimate of how soon the investment will pay for itself 
in reduced costs. 



Figure 6-1 Investment Recovery 

63.1 Payback 

Payback determines how quickly a project recovers its initial investment or project costs. For 
reuse, the inflow of benefits occurs when the organization reuses existing components, whether 
they are architectures, models, designs, requirements, documentation, or actual software assets. 
The point when the inflow exceeds the project outlay is referred to as the break-even point 
[Figure 6-1]. The formula for calculating payback is: 

Payback-- 

Avenge Annual Benefit 


Where: 

Project Co6t« Total start-up and ongoing cost of reuse 

Average Annual Benefit = Actual cost savings over the life of the pro je ct 
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Example 

Two approaches have been identified by the organization with the following cost and benefit 
data. 

1 

Project Cost $300,000 

Average Annual Benefit $150.000 

Payback (1) $300,000 * 2 Years 
$150,000 

Payback (2) $100,000 «= 1.67 Years 
$60,000 


63.2 Estimating the costs 

Estimating the dollar value of the cost includes: 

1. Reuse infrastructure hardware and software costs pertains to purchase, rental, lease 
of operational hardware and software required to implement the proposed system(s). 
This should include all new equipment and upgrades to existing systems. All rental 
and lease costs should be annualized. 

2. Software development costs pertain to all costs associated with creating new 
reusable software (domain models, architectures and reusable components), and 
modifying or classifying existing software. 

3. New operating costs, represented by any new operating costs or increased operating 
costs resulting from this implementation. For instance, personnel training, storage, 
facility etc. 

4. Maintenance costs for components, hardware, and system administration. 

Output 

By collecting the financial data and applying the formulas, the organization will be able to 
more accurately estimate the costs and benefits of proposed solutions, as well as the return on 
investment. The accurate identification, collection, and analysis of data will result in: 

1. Estimate for one-time design and implementation costs of reuse. 

2. Estimates of the ongoing costs of implementing reuse. 

3. A summary analysis of the economics of the proposed reuse infrastructure. 


2 


$100,000 

$60,000 
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4. Identification and documentation of intangible considerations which may affect 
management’s decision. 





STARS-VC-BOKVOOi/OC 


28 February 1994 


APPENDIX A - Workproducts 
A.1 Organizational Analysis Sample Outline 

1. Develop executive summary portion of the feasibility report. 

a. Identify all of the major findings resulting from the survey. 

b. Identify the recommended solution alternatives (if there are multiple) and any 
long or short term solutions. 

c. Identify the major goals and objectives that the proposed solutions will address. 

d. Identify the cost and benefits of the proposed solution(s). 

2. Develop a summarized version of the method that was used 

Identify the people that were interviewed and the types of materials that were 
utilized, (surveys, questionnaires etc.) 

3. Define the organization’s business long range goals [3.4.1] 

a. Organizational Chart 

b. Correlate goals to organizational level 

c. Identify any problems and solutions 

4. Determine Domain-Specific infrastructure [3.4.2] 

a. Analysis of domain 

b. Context diagram if applicable 

c. Future trends 

d. Domain-Specific goals 

5. Define the current software development environment [3.4.3] 

a. Operational hardware and software 

b. Quantity of software produced 

c. Quantity and quality of assets currently available 
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d. Controls that are in place, for metrics collection and analysis 

6. Critical success factors [3-4 on page 12] 

a. List critical assumptions, critical decisions and critical information 

b. List individual CSFs 

7. Define the recommendation being proposed 

a. Include objectives and goals which will be met by implementing reuse 

b. Identify potential constraints in the form of impact on the organization 

c. Identify the benefits of following the recommendation 

d. Identify the scope of the proposed recommendation 

8. Complete the report and include appendices that provide supporting documentation 
for the body of the report 

a. Include interview data 

b. Include sample questionnaires 

c. Include appropriate documentation that was collected or developed during the 
interview process 

A J2 Requirements/Implementation Study Sample Outline 

1. Executive summary portion of the requirements analysis report 

a. Identify all of the major findings resulting from the analysis 

b. Identify the recommended solution alternatives (if there are multiple) and any 
long or short term solutions 

c. Identify the major goals and objectives that the proposed solution will address 

d. Identify the cost and benefits of the proposed solution(s) 

2. Summarized version of the study method that was used to gather the information 
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Identify the people that were interviewed and the types of materials that were 
utilized, (surveys, questionnaires, etc.) 

3. Define the organization’s business requirements [3.4] 

a. Goals and Objectives 

Organizational Chart 

Correlate goals to organizational level 

Identify any problems and solutions 

b. Critical Success Factors 

List critical assumptions, critical decisions and critical information 
List individual CSFs 

c. Current Technology Structure 

Operational hardware and software 

Quantity of software produced 

Quantity and quality of assets currently available 

Controls that are in place, for metrics collection and analysis. 

d. Summation of business requirements 

4. Software process requirements [4.3] 

a. Current Software Processes 

b. Recommended reuse software processes to be incorporated into current software 
development processes 

c. Reuse usage scenarios 

d. Recommended changes/additions to software development processes 

e. Current automated support fa- software processes 

5. Domain Requirements [4.4] 

a. Assessment of domain 

b. Context diagram if applicable 
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c. Future trends 

d. Domain-specific goals and requirements 

e. Domain readiness assessment (domain model, generic architecture, assets and 
domain expertise) 

6. Technology Insertion Impact Assessment [4.5 and 6} 

a. Summarize the potential impact to personnel and equipment 

Current Personnel/Required Personnel 
Training necessary 

Current Equipment/Required Equipment 

b. Estimate 

User requirements 

Cost of reuse infrastructure 

Return on Investment 

Present alternative costing scenarios 

c. Financial Feasibility 

Equipment cost 
Training cost 
Personnel cost 

7. Define the recommendations being proposed. 

a. Identify objectives and goals which will be met by implementing reuse 

b. Identify potential constraints in the form of impact on the organization 

c. Identify the benefits of following the recommendations 

d. Identify the scope of the proposed recommendations 

8. Ensure that the following issues are addressed: 

a. Major Risks 

b. Outside consulting or support services required 
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c. Scheduling requirements for implementation 

9. Complete the report aud include appendices that provide supporting documentation 
for the body of the report 

a. Include interview data 

b. Include sample questionnaires 

c. Include appropriate documentation that was collected or developed during the 
interview process 

A3 Reuse Implementation Plan Sample Outline 

Reuse implementation should occur in a detailed, tailored, phased approach. Just as no two 
organizations are exactly alike, no two implementation plans are exactly alike. 

1. Executive summary portion of the Reuse Implementation Plan. 

a. Identify all of the major decisions made as a result of the plan. 

b. Identify the recommended solution alternatives (if there are multiple) and any 
long or short term solutions 

c. Identify the major goals and objectives that the proposed solution will address 

d. Identify the cost and benefits of the proposed solution(s) 

2. Summarize the method that was used to gather the information 

Identify the people that were interviewed and the types of materials that were 
utilized, (surveys, questionnaires, documentation, etc.) 

3. Define the Organization’s [3.4.1] 

a. Reuse mission 

b. Reuse vision 

c. Reuse goals and objectives within the organizational chart 

4. Identify the critical processes that will be improved/implemented 
a. In the software development practices 
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b. In the management practices 

5. Summarize the potential impact to personnel and equipment [4.5] 

a. Current personnel/required personnel 

b. Training necessary 

c. Current equipment/required equipment 

6. Phased plan for reuse process insertion 

a. Project management 

b. Reuse insertion into current processes [4.3] 

c. Asset creation [5.3] 

process decisions 

equipment, tools, training, personnel decisions 

d. Asset management [5.4] 

Decision on library type, resources, in-house or third party) 
Implications to organization 
Personnel Training 

e. Asset usage [5.5] 

Type of assets that will be available 
Personnel training 

f. Automated tools support for reuse infrastructure 

g. Measurement plan 

7. Financial Cost [4.5 and 6] 

a. Equipment cost 

b. Training cost 

c. Personnel cost 
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8. Ensure that the following issues are addressed within the Reuse Implementation Plan: 

a. Major Risks 

b. Outside consulting or support services required 

c. Scheduling requirements for implementation. 

9. Complete the report and include appendices that provide supporting documentation 
for the body of the plan 

a. Include interview data 

b. Include sample questionnaires 

c. Include appropriate documentation that was collected or developed during the 
planning process 
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APPENDIX B - Related Documents. 


This appendix will 

• Describe the CARDS documents; 

• Describe when the CARDs documents are most useful for reuse project p lanning; and 

• Provide a table relating the CARDS documents and other documents to the reuse 
project planning phases. 

B.l CARDS Documents 

B.1.1 Acquisition Handbook 

The Acquisition Handbook, is aimed towards all Government Program Managers and their support 
personnel, such as Contracting Officers and Administrators, procurement attorneys, and program 
control, involved in systems, subsystems and component acquisition. The concepts discussed 
assume that the reader has at least three years in acquisition. 

The Handbook assists them in incorporating software reuse into all phases of the acquisition 
life cycle, from concept exploration to Post Deployment Software Support (PDSS). It is not a 
"cookbook" for every possible reuse issue or strategy, rather it is meant to help develop and 
tailor reuse programs. 

The goal of the Acquisition Handbook is to encourage software reuse during the acquisition and 
maintenance portions of the life cycle process, ranging from planning the acquisition strategy 
through awarding the contract to managing the effort and follow-on support. Software reuse 
guidance is presented by providing methods, examples, recommendations and techniques to 
implement various reuse strategies throughout the acquisition life cycle. 

This Handbook can be used during the development and execution of the Reuse Implementation 
Plan. 

B.I.2 Component Provider’s and Tool Developer’s Handbook 

The Component Provider’s and Tool Developer’s Handbook was developed under the Central 
Archive for Reusable Defense Software (CARDS) Program to help facilitate software reuse 
adoption. Government developers and software industry vendors supporting government 
acquisitions are provided with guidance far developing/creating domain-specific reusable 
components and tools supporting reuse. The goal of this handbook is to stimulate the 
development and commercialization of large scale components and tools for vertical domains. 
Focus is placed on architecture-centric, library-assisted software reuse. It is assumed that the 
reader is familiar with the design and development of software. The audience for this handbook 
consists of; 
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• government: domain and System Program Office (SPO) engineers, 

* contractors: component creators and tool developers. 

B.1J Direction Level Handbook 


The Direction Level Handbook is directed towards acquisition executives of all the services to 
facilitate the institutionalization of software reuse. The audience of Program Executive Officers 
(PEOs), Designated Acquisition Commanders (DACs), and their supporting staff, are provided 
with a framework to assist them in establishing plans to manage reuse across their systems 
and to reach the goals outlined in the DOD Software Reuse Vision and Strategy document 
Considerations are provided to assist in incorporating software reuse into the initial planning 
stages of an acquisition, as well as at critical points within the acquisition life cycle. The 
options provided the executive allows him to gain the greatest benefits from software reuse 
while optimizing the use of shrinking resources. 

This Handbook can be used to determine the reuse objectives, business requirements, domain 
requirements, reuse/technology infrastructure requirements and the critical success factors during 
the Organizational Assessment and Requirements/Implementation Study activities. 

B.1.4 Engineer’s Handbook 

The Engineer’s Handbook was developed under the Central Archive for Reusable Defense 
Software (CARDS) Program to help facilitate advances in software reuse tec hniques and 
technologies. This document provides guidance to Government System Program Office (SPO) 
Engineers on envisioned changes to their duties and responsibilities as domain-specific software 
reuse becomes incorporated into mainstream DoD system/software acquisition and enginee ring 
processes. 

The intended audience of this Handbook is SPO Engineers who are responsible far pre- 
Request far Proposal (RFP) engineering activities, proposal evaluation, monitoring of engineering 
activities after a contract is awarded, and monitoring of ongoing sustaining engineering efforts 
(or maintenance) of fielded products. 

To fully utilize the concepts in this Handbook, it is recommended that the reader be familiar with 
software development techniques and methodologies, existing Government regulations (such as 
DOD-STD-2167AJvUL-STD-499, MH^STD-1521B, and emerging DOD-STD- 498/SDD), and 
the acquisition process. 

B.1.5 Library Development Handbook 

The process of developing a domain-oriented reuse library is elaborate. This Library 
Development Handbook provides an overview of the phases involved in developing such a 
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library: domain analysis, library encoding, and library population. This Handbook presents a 
generic library population process that has been developed by the Central Archive for Reusable 
Defense Software library development team. This Handbook enumerates specific instructions and 
examples for populating a domain-oriented reuse library, based on this library population process. 
We are currently assessing the implications of legal issues on our policies and procedures. 
Appropriate risk reduction procedures will be detailed in subsequent releases. 

B.1.6 Library Operation Policies and Procedures 

The Library Operation Policies and Procedures (LOPP) manual consists of two volumes. 
Combined, these volumes serve as a comprehensive guide for implementing and m aintainin g a 
reuse library. Volume One outlines recommended Policies and Procedures for Library operations. 
Volume Two provides detailed Operational Instructions, or "day-to-day" processes. Volumes 
One and Two are partitioned to allow for maximum modularity and ease of use for the document 
user. 

B.l.6.1 Volume One, Policies and Procedures 

Volume One, Policies and Procedures, is aimed toward upper-level management through the 
technical supervisor level and provides a high level view of the policies and procedures fa- 
operations. Volume One provides access to information concerning strategies for managing and 
maintaining an existing reuse library system, including recommendations on how to implement 
operations of the library, tables showing suggestions on how to assure task accountability and 
completion, and an expected level of knowledge fa - the staff at hand. 

This volume of the LOPP can be used to develop and execute the requirements fa the asset 
management portion of the Reuse Implementation Plan. 

B.l.6.2 Volume Two, Operational Instructions 

Volume Two, the Operational Instructions, targets the technical individual who will be 
implementing the policies and procedures of Volume One. The Operational Instructions provide 
detailed descriptions of the day-to-day happenings fa implementing, and m aintainin g a reuse 
library. This volume provides quick access to the specific area of interest and allows the reader to 
retrieve only that information specific to their area of interest or concern. In addition to outlining 
the CARDS daily operations, Volume Two contains the forms referenced in this document 

This volume of the LOPP can be used to develop and execute the asset management portion of 
the Reuse Implementation Plan. 

B.1.7 Market Study 

The Market Study will supply the Central Archive fa Reusable Defense Software (CARDS) 
program with information regarding the current state-of-the-practice of software development 
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and maintenance within the military services. Results of analysis of collected data will reflect 
current practices, as well as identified needs within each military service for establishment of 
a suitable infrastructure to enable reuse. Full comprehension of the software needs of potential 
reusers is required before CARDS can address its ultimate goal of facilitating widespread software 
reuse throughout the DoD. The focus of results will therefore be geared toward facilitating the 
CARDS process of institutionalizing software reuse within the Department of Defense (DoD) by 
more finely concentrating our development, technology transfer and franchising efforts toward 
satisfaction of identified requirements. 

B.1.8 Technical Concept Document 

The Central Archive for Reusable Defense Software (CARDS) program is a concerted DoD 
initiative to transition advances in the techniques and technology of library-aided, architecture¬ 
centric, domain-specific software reuse into mainstream DoD software procurement. This 
technology transition effort involves the development of a domain-specific reuse library for 
researching technologies and methodologies for creating reuse libraries. This document describes 
the technical concepts employed towards the development of the CARDS Command Center 
Library. 

CARDS views a reuse library as reusable software components, a library model and supporting 
library applications. This view, and it’s consequences on library development are presented 
in this document. A discussion of model-based reuse library infrastructure presents a model- 
based view of library development, with an emphasis on distinctions between domain and library 
modeling. 

The component qualification process is presented as an integral part of the library development 
process. Modeling of the command center library has evolved to support development and 
integration of various reuse library applications. The CARDS system composition and component 
qualification tools are discussed. 

This document also presents technical aspects of the operational library, such as distribution 
options (e.g., AFS), reuse library security issues (an overview of the CARDS security analysis 
is presented), and advances made in interoperation between reuse libraries. 


B.1.9 Training Plan 

The Central Archive for Reusable Defense Software (CARDS) Training Plan serves as a 
comprehensive guide for creating training courses and training materials on domain-specific 
reuse for Department of Defense (DoD) organizations, DoD contractors, system engineers, and 
university professors. The Training Plan provides guidance for conducting three specific software 
reuse training courses for four different audiences. The intent of the courses in the Training Plan 
is to demonstrate how software reuse can reduce development and maintenance time and costs, 
reduce project risks, and increase productivity. 


PageB-4 





STARS-VC-BOUVOOl/OO 


28 February 1994 


B.1.10 Application Engineering With Domain-Specific Reuse Course 

This course description was developed under the Central Archive for Reusable Defense Soft 
ware (CARDS) Program to help facilitate advances in software reuse methods. This course 
description provides guidance on developing a course to teach system and software engineers 
how to incorporate domain engineering products into the software development process. 

The course outlines begins by introducing students to reuse and domain-specific reuse. Do main 
engineering is defined and the products of domain analysis are explored. Reuse libraries are 
discussed, and the students are instructed in how to incorporate domain engineering products, 
located in a reuse library, into the application engineering process. The course was developed 
for presentation to both Government and industrial personnel. It can be tailored for presentation 
at the university level. 

B.2 Document Matrix 

This table correlates the CARDS documents, described above, and other related reuse oriented 
documents to the reuse project planning phases. 

Table B-l Documents Related to Project Planning Phases 


Document 

Organizational 

Analysis 

Requirement/ Imple¬ 
mentation Study 

Reuse 

Implementation Plan 

Execute Reuse Plan 

Air Force Software 

Reuse Implementation 

Plan [AIR92] 



XXX 

XXX 

The Army Strategic 

Software Reuse Plan 

[ARMY92] 

XXX 

XXX 

XXX 

XXX 

ASSET Set Up Plans 

[ASSET91] 


XXX 

XXX 


ASSET Operations 

Plan {ASSET92] 



XXX 

XXX 

CARDS Acquisition 

Handbook 

[CARDS 94a) 



XXX 

XXX 

CARDS Direction 

Level Handbook 

[CARDS94b] 

XXX 

XXX 



CARDS Engineer’s 

Handbook 

(CARDS 94c] 
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Document Organizational Requirement/ Imple- Reuse Execute Reuse Plan 

Analysis mentation Study Implementation Plan 

CARDS Library De- xxx an 

veiopmem Handbook 

[CARDS93a]_ 

CARDS Market Study xxx 

[CARDS 94d] __ 

CARDS Training Plan xxx xxx 

[CARDS 94e] _ _ 

CARDS Library Oper- xxx xxx 

aborts Policies and 

Procedures 

[CARDS94fj 

CARDS Technical xxx xxx 

Concepts Document 
[CARDS 94 g] 

CARDS Engineer’s xxx xxx 

Handbook 

[CARDS94h] 

CARDS Component xxx xxx 

and Tool Developers 
Hand book 
[CARDS94i] 

CARDS Application xxx xxx 

Engineering With 
Domain-Specific 
Reuse Course De¬ 
scription [CARDS93c] 

Application of Feature xxx xxx xxx 

Oriented Domain 

Analysis to the Army 

Movement Control 

Domain [COHEN91] 

Criteria for Compar- xxx xxx 

ing Reuse-Oriented 
Domain Analysis 
Approaches [DIAZ91] 

» ■ jza.n&rv** :, <»i . . . i n ■ »■ M^HHUMramuHUN 

Domain Analysis xxx xxx xxx 

Guidelines [DISA92b] 
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Document Organizational Requirement/1 tuple- Reuse Execute Reuse Plan 

Analysis mentation Study Implementation Plan 

DoD Software Reuse xxx xxx xxx 

Initiative Vision and 
Strategy [DOD92] 

NASA Manager's xxx xxx xxx xxx 

Handbook for Soft¬ 
ware Development 
[NASA90] 

NASA Recommended xxx xxx xxx xxx 

Approach to Software 

Development 

[NASA92] 

NATO Standard for xxx xxx 

the Development of 
Reusable Software 
Components [NATOa] 

NATO Standard for xxx xxx 

Management of a 

Reusable Software 

Component Library 

[NATOb] 

NATO Standard for xxx xxx 

Software Reuse 
Procedures [NATOc] 

Navy Reuse Imple- xxx xxx xxx xxx 

mentation Plan 

[NAVY93] 

Software Architecture xxx xxx xxx 

[PERRY91] 

Draft Concept of Op- xxx xxx 

era no ns Document for 

the National Test Bed 

Software Reuse 

Program [SDI091] 

SPA ft SCE - Sorting xxx xxx 

it Out [SEI92] 

SPC Reuse Adoption xxx xxx xxx 

Guidebook [SPC92a] 

SPC The Reuse Capa- xxx xxx xxx 

bility Model [SPC92b] 
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acquisition 

application domain 

architecture model 

architecture modeling 

assessment 

asset 

classification scheme 

context 

critical assumptions 

critical decisions 

critical information 

critical success factor (CSF) 

domain 


APPENDIX D - Glossary 

The phase of library population in which potential soft¬ 
ware products are identified, screened and then evaluated 
far inclusion in the library. 

The knowledge and concepts which pertain to a particular 
computer application. 

A model that represents the interrelationships between 
system elements and sets a foundation for later require¬ 
ments analysis and design steps. 

The process of creating the software architecture(s) that 
implements a solution to the problems in the domain. 

The act of evaluating. 

A set of reusable resources that are related by virtue of 
being the inputs to various stages of the software life 
cycle, including requirements, design, code, test cases, 
documentation, etc. Components are the fundamental 
elements in a reusable software library. 

The organization of reusable software components ac¬ 
cording to specific criteria. 

The circumstances, situation, or environment in which a 
particular system exists. 

A group of assumptions about a business segment, 
competitor, or industry that supports or validates an 
organization’s critical success factors. 

The decisions that must be made by an organization to 
have an impact on its critical success factors. 

The information that is required by an organization’s op¬ 
erational system to enable them to support the organiza¬ 
tion’s critical success factors. 

An internal or external business-related result that is 
measurable and that will have a major influence on 
whether a business segment meets its goals. 

An area of activity or knowledge containing applications 
which share a set of common capabilities and data. 
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domain analysis 


domain analyst 


domain architecture 


domain constraints 


domain engineering 


domain expert 

domain model 


domain modeling 
domain-specific library 
domain-specific reuse 


The process of identifying, collecting, organizing, analyz¬ 
ing, and representing the relevant information in a domain 
based on the study of existing systems and their devel¬ 
opment histories, knowledge captured from domain ex¬ 
perts, underlying theory, and emerging technology within 
the domain. 

An individual skilled in domain analysis methodologies. 
The Domain Analyst is responsible for defining the 
language, tools, and techniques used in performing the 
domain analysis. This person also documents the domain 
model and may be responsible for defining any generic 
architectures associated with the domain. 

High-level paradigms and constraints characterizing the 
commonality and variances of the interactions and rela¬ 
tionships between applications within a domain. 

Represent the mission-level requirements identified 
within the boundaries of the domain. They determine 
the functionality of the system expressed in terms and 
language dominant within the domain. 

An encompassing process which includes domain analy¬ 
sis and the subsequent construction of components, meth¬ 
ods, tools, and supporting documentation that address the 
problems of system/subsystem development through the 
application of the knowledge in the domain model and 
software architecture. 

An individual with extensive knowledge of a particular 
domain. 

A definition of the functions, objects, data, and relation¬ 
ships in a domain, consisting of a concise representation 
of the commonalities and differences of the problems of 
the domain and their solutions. 

The process of encoding knowledge about a domain into 
a formalism. 

A library whose components are bound by a specific 
domain.' 

Reuse that is targeted for a specific domain (as opposed 
to reuse of general purpose workproducts). It typically 
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feature 

franchise 


generic architecture 

goal 

infrastructure 

knowledge blueprint 
library 

library model 
library population 


involves reuse of larger workproducts (subsystems, ar¬ 
chitectures, etc.) that general purpose reuse. 

A prominent or distinctive user-detectable aspect, quality, 
or characteristic of a software system or systems. 

An organization (government/contractor/commercial) 
that is committed to developing a domain-specific reuse 
capability that: 

1. fains reciprocal obligations and a cooperative part¬ 
nership with CARDS 

2. has a business agreement with CARDS that enumer¬ 
ates the range and level of services to be provided by 
CARDS and obtained from the franchisee. 

3. shares a model-based, library-assisted technical vision 
with CARDS 

A collection of high-level paradigms and constraints that 
characterize the commonality and variances of the inter¬ 
actions and relationships between the various components 
in a system. 

1. A statement of an organization’s medium-to-long- 
term target or direction of development. A goal is 
achieved when all objectives relating to it have been 
achieved. Typically, goals do not have exact timetables 
or achievement measures associated with them. 2. 
Specific targets that a business segment intends to meet 
within a specified time frame to further the achievement 
of more general objectives. 

1. The basic underlying framework or features. 2. The 
basic installations and facilities on which continuance and 
growth of an organization depend. 

A flexible plan to transition knowledge to the community. 

A collection of components that are cataloged according 
to a common classification scheme and a set of appli¬ 
cations that provide a mechanism to browse and retrieve 
components. 

A model that represents the domain components and the 
relationships between them. 

The process of acquiring/developing components in sup- 
pot of the library model. 
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memorandum of understanding 
mission 

mission statement 

model 

modeling 

objective 

reusable component 

reuse 

reuse library 

reuser 

software architecture 


An agreement stating terms of cooperation between two 
entities. 

A general statement of the purpose and nature of the 
enterprise. 

A broad description of an enterprise’s purpose, policies, 
and long-range strategy and vision. 

A representation of a real-world process, device, or 
concept. 

The process of creating a model. 

An end or target state that is achieved by accomplishing 
all critical success factors related to it. Objectives 
are short-term (12 to 24 months or less), with defined 
achievement measures. 

A component (including requirements, designs, code, 
test data, specifications, documentation, expertise, etc.) 
designed and implemented for the specific purpose of 
being reused. 

The application of existing solutions to the problems 
of system development. Reuse involves transfer of 
expertise encoded in software-related work products. The 
simplest form of reuse from software work products 
is the use of subroutine/subprogram libraries for string 
manipulations or mathematical calculations. 

A library specifically designed, built, and maintained to 
house reusable components. 

One who implements a system through the reuse process. 

High-level paradigms and constraints characterizing the 
structure of operations and objects, their interfaces, and 
control to support the implementation of applications in a 
domain. Includes the description of each software com¬ 
ponent’s functionality, name, parameters and their types 
and a description of the component’s interrelationships. 
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